dd atomic multi-operation batch() API with single passkey approval ( - #650

Thanks for this — the design is right and the rollback test is a good instinct. Two blockers and one thing that needs a maintainer decision.

1. It does not compile

cargo test -p invisible-wallet fails on main + this branch:

error[E0277]: the trait bound `BatchInvocation: Clone` is not satisfied
   --> invisible_wallet/src/lib.rs:466:39
466 |         for invocation in invocations.iter() {
    |                                       ^^^^
note: required by a bound in `soroban_sdk::Vec::<T>::iter`
923 |         T: IntoVal<Env, Val> + TryFromVal<Env, Val> + Clone,

soroban_sdk::Vec::iter() requires Clone on the element type. One line fixes it:

#[contracttype]
#[derive(Clone)]          // <- add this
pub struct BatchInvocation {

I applied that locally to check nothing else was hiding behind it: 92 tests pass, including your test_batch_rolls_back_when_later_invocation_fails. So this is the only code change needed.

2. The description claims work the diff does not contain

The body says __check_auth was "verified (and if necessary, updated) … to correctly validate a single signature/assertion against multiple auth contexts", and makes strong security claims on that basis — replay resistance, no partial authorization.

__check_auth appears zero times in the diff. Nothing was changed there, and nothing in the PR demonstrates it was tested.

That matters because the claims may well be true — batch() calls require_auth() on current_contract_address(), and Soroban binds the auth context to the function and its arguments, so the assertion should cover the exact invocation list. But that is an argument, not evidence, and this is the most security-critical function in the project. Please either state it as reasoning about existing behaviour, or add the multi-context test your own "How to Test" section lists as item 5.

Relatedly, the body still contains an unresolved note to yourself: "(Confirm and state explicitly if __check_auth changes altered any stored auth state format.)"

3. Contract changes have a deployment cost — maintainer call

Any change to invisible_wallet/src/lib.rs changes the WASM hash. The mainnet contract is source-verified against contracts/expected-hashes.json (invisible_wallet.wasm = b485f817…9ea5), and that byte-for-byte match is a load-bearing claim for us.

Merging this without regenerating hashes means main no longer matches what is deployed. Existing mainnet wallets also will not have batch() until they upgrade. Not your responsibility to resolve, but worth knowing why this one cannot merge on a green test run alone.

Fix the Clone derive and I will re-run the suite.

Approved and merging — into contracts/next, not main, and I've pushed the rework to your branch (5dd1859).

You closed both blockers. The #[derive(Clone)] is in, and you went past what I asked on the second point: rather than reword the __check_auth claim, you wrote test_check_auth_multi_context_spend_limit_enforced, which sums the spend across every Contract context and asserts two 300-unit contexts are rejected against a 500 limit. That is the right test — it proves the limit is enforced over the batch as a whole rather than per-invocation, which is exactly the property a batching API could silently break. Verified: 93 tests pass, both new ones among them.

The implementation is right to be four lines. require_auth() on current_contract_address() once, then invoke each target — Soroban binds the authorization to the function and its arguments, so one assertion covers this exact invocation list and a different list cannot be substituted under the same signature. Nothing more is needed, and anything more would be a place for a bug to live.

Why contracts/next rather than main. Any edit to invisible_wallet/src/lib.rs changes the WASM hash, and reproducible-build.yml fails on drift from contracts/expected-hashes.json. That file records the hash the live mainnet contract is source-verified against — a claim we rely on. Merging to main would break the check and, worse, quietly make that claim untrue until a redeploy. So this lands on the staging branch for the next contract release, where it will get its hash regeneration and deploy together. Not a reflection on the work; it is where contract changes belong.

One rework. The SDK half was written against the pre-#662 useInvisibleWallet.ts. That file is now a 76-line React binding over core.ts, so taking your copy would have restored the entire pre-refactor implementation — the same accidental revert I hit on #663 today, and it merges without a conflict marker. I ported batch() into InvisibleWalletCore instead, which means the Vue adapter gets it for free — precisely what that extraction was for. BatchOperation and BatchResult re-export from useInvisibleWallet.ts, so the public import path is unchanged from what you wrote.

I kept your ScMap construction as-is and commented why it is shaped that way: a #[contracttype] struct arrives as a symbol-keyed map, so target / func / args must match the contract's field names exactly — a mismatch fails at simulation with a conversion error that names none of them, which is a miserable thing to debug.

Verified: cargo test -p invisible-wallet 93 passed; SDK tsc --noEmit clean, 262 tests across 23 suites passing.

Good design, and the rollback test was the right instinct from the start.